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I.  INTRODUCTION 


The  goal  of  the  Naval  Postgraduate  School  Signal 
Processing  and  Display  Laboratory  is  to  provide  a facility 
for  research  and  education  in  the  field  of  computer  science. 
The  laboratory  is  built  around  a pair  of  Dioital  Equipment 
Corporation  PDP-11/50  processors.  One  processor  is 
primarily  used  to  service  multiuser  program  development 
activities.  The  other  processor  supports  several  graphics 
display  devices  and  provides  a dedicated  environment  for 
research  and  development  in  the  areas  of  operating  systems^ 
computer  graphics  and  sigi.jl  processing.  Figure  1 shows  the 
present  hardware  conf i gurat i on  of  the  laboratory. 

The  UNIX  operating  system  T 71 , a time-sharinq  system 
developed  at  Pell  Laboratories/  was  chosen  as  the  system 
best  suited  to  support  the  goals  stated  above.  UNIX's 
inherent  file  system  flexibility  and  the  availability  of 
system  source  code  written  in  the  high  level  programming 
language/  "C"/  provide  an  excellent  environment  for 
operating  system  development  and  research.  The  availaoility 
of  a dedicated  processor  as  a developmental  tool  further 
enhances  this  environment. 

Due  to  the  unique  and  demanding  requirements  placed  on 
the  display  processor's  operating  system  by  graphics  devices 
and  signal  processing  eouipment/  it  was  determined  that  the 
standard  version  of  UNIX  in  use  ( henceforth  simply  referred 
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to  as  UNIX  ) was  unsatisfactory.  This  thesis  proposes  an 
extension  to  the  UNIX  system  in  the  form  of  a new  memory 
management  scheme.  The  approach  taken  was  to  implement 
process  segmentation  with  provision  for  data  space 
allocation  and  alignment  within  a specified  memory  region. 
This  approach  was  feasible  and  attractive  because  the 
PDP-11/50  is  equipped  with  a memory  management  unit  (MMU) 
that  supports  segmentation.  Addi t ional 1 y,  segmentation 
provides  extra  flexibility  in  resident  process  manioul at  ion. 
UNIX  allocates  process  soace  as  a single  contiguous  unit  in 
main  memory.  Segmentation  allows  management  of  process 
segments  as  seoarate  entities.  This  provides  the  necessary 
tool  for  selective  allocation  of  memory  soace  to  an 
individual  seament. 

This  latter  feature  is  particularly  attractive  in  a 
svstem  configured  with  multiDorted  memory.  As  shown  in 
Figure  1#  the  display  processor  has  access  to  two  dual- 
ported  memory  areas*  one  shared  with  a signal  processing 
controller,  the  other  shared  with  a slave  processor  for  the 
refresh  graphics  display  devices.  Due  to  the  real-time 
requirements  of  these  devices,  independent  access  to  data  in 
the  shared  region  is  necessary.  Otherwise,  the  display 
processor  will  not  be  able  to  supoort  mu  1 t i prooramm i ng.  A 
segmented  memory  manaaer  would  provide  the  features 
necessary  to  suoport  these  real-time  reoui rements. 

Two  modifications  of  the  UNIX  operating  system  were 
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implemented  and  tested  as  a result  of  this  thesis.  One  was 
a previously  designed  C«J  » but  unimolemented,  segmented 
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memory  manager  version  (SUNIX).  The  other#  a shared- 
segmented  version  CSSUNIX)#  was  a further  modification  of 
SUNIX  which  implemented  the  alianment  of  a process's  data 
soace  within  a shared  memorv  reqion.  Real-time  processing 
was  supported  by  locking  the  process  image  in  main  memory 
once  the  shared  region  had  been  acquired. 

Testing  of  SUNIX  and  SSUNIX  included  benchmark 
measurements  and  operation  in  the  general  multiuser 
environment.  Performance  was  almost  identical  to  that  of 
UNIX.  Additionally#  SSUNIX  was  tested  on  the  display 
processor  and  successfully  fulfilled  the  objective  of  data 
space  alignment  with  system  protection.  Amplification  of 
these  results  is  provided  in  Chapter  V of  this  thesis.  In 
addition/  recommendations  are  included  for  applications  and 
utilization  of  SUNIX  and  SSUNIX  in  the  Signal  Processing  and 


Display  Laboratory 


FIGURE  I.  Signal  Processing  and  Display  Laboratory 


II.  BACKGROUND 


A.  PREVIOUS  WORK 


Three  previous  thesis  projects  which  are  closely 
associated  with  the  development  of  SUNIX  and  SSUNIX  are 
discussed  below.  It  should  be  noted  that  a specific  area  of 
concern  in  all  three  papers  is  the  development  of  svstem 
support  for  the  special  devices  on  the  display  processor. 


1.  Partitioned  Segmented  Memory  Manaaer 

In  this  thesis  f41 , Emery  reports  an  investigation 
of  the  applicability  Of  paaing  and  segmentation  to  memory 
management  in  UNIX.  Two  memory  managers  were  aesigned  to 
support  this  investigation:  a partitJoned  segmented  version 
(PSUNIX)#  and  a simpler  segmented  version  (SUNIX).  The 
primary  Consideration  in  the  design  effort  was  that  the 
segments  be  separate  and  independently  manageable  in  main 


memo  ry , 


he  segmentation  chosen  was  the  existing  natural 


division  into  a process  control  blocx#  a data  segment 
(including  non-shared  text)*  and  a User  stack.  Shared  text 
segments  were  handled  in  much  the  same  manner  as  in  UNIX. 
SUNIX  was  designee  to  manaae  each  complete  segment 
independently.  It  was  this  design  effort  that  Provided  a 
foundation  for  the  development  of  SSUNIX.  PSUNIX  further 
broke  down  each  of  the  segments  into  variable-size  blocks. 

Testing  of  PSUNIX  was  accomplished  bv  using 


benchmark  measurement*  to  analyte  Its  performance  in 
relation  to  ' UNIX.  The  experimental  results  clearly 
indicated  that  the  performance  of  PSUNIX  and  UNIX  were 
nearly  identical  over  a wide  range  of  available  User  memory 
space.  Emery  suggested  that  this  aporoximate  eguality  of 
pergormance  indicated  that  the  disadvantage  of  the  increased 
amount  of  swapping  in  PSUNIX  was  offset  by  a reduction  in 
the  number  of  processes  swapped.  He  attributed  this  to 
reduced  external  fragmentation  with  PSUNIX.  However#  due  to 
the  relative  complexity  of  PSUNTX  # Emery  recommends  that  the 
simpler  SUNIX  be  completed  and  implemented  as  a viable 
al ternat i ve. 

2.  Int er-Processor  Graphics  Support  System 

Visco  1121  investigated  a multiple  processor  system 
configuration  to  support  a real-time#  interactive  graphics 
package.  UNIX  was  redesigned  to  implement  a real-time 
system  call  and  a master-slave  relationship  between  the 
display  processor  and  a dedicated  graphics  processor. 
Specifically#  he  designed  the  system  support  routines 
necessary  for  integration  of  the  PDP-11/50#  PDP-11/3U#  and 
Vector  General  ( VG)  Display  Processors.  For  testing 
purposes#  i nter-processor  communications  were  simulated  on 
the  PDP-li/50#  since  the  pDP-ll/3fl  slave  processor  was  not 
aval  1 aol e for  use. 

The  master-slave  processor  configuration  was 
conceived  as  an  answer  to  the  problem  of  refresh  graphics 
devices  having  a high  level  of  direct  memory  access  (DMA) 


requests  end  a requirement  for  rest-time  system  support* 
DMA  is  the  transfer  of  data  directly  to  or  from  memory  by  a 
peripheral  device/  without  processor  suoervision.  This 
configuration  required  shared  memory  and  the  system  support 
software  to  align  a process  image  in  the  shared  region. 
Memory  management  hardware  on  the  slave  processor  (21 
permitted  a 32  thousand  (K)  word  address  range.  The  system 
designed  bv  Visco  allocated  the  entire  process  image  on  a 
32k  word  boundary.  System  protection  was  not  achieved  since 
other  processes  were  allowed  to  overlap  into  this  region. 

Visco  suggested  an  implementation  of  Emery’s  SUMIX 
as  a method  of  allocating  only  the  graphics  process’s  data 
soace  to  the  shared  region  of  memory.  Since  DMA  by  the 
slave  processor/  acting  in  behalf  of  the  graphics  device/ 
was  highly  concentrated  in  data  soace/  this  memory 
allocation  scheme  would  more  efficiently  utilize  the  limited 
amount  of  shared  memory.  SSUNIX/  with  the  added  features  of 
generalized  multioorted  memory  applications  and  system 
protection/  was  developed  as  a result  of  this  suggestion. 

3.  Loosely-Coupled  Multiprocessor  System 

Visco's  work  was  directed  primarily  toward  the  main 
processor  in  the  proposed  mu  1 1 i processor  system  for  the 
laboratory.  A thesis  bv  Gray  1*5)  addresses  the  development 
of  an  operating  system  for  the  slave  processor.  Although 
not  directly  related  to  the  problem  of  memory  management  in 
UNIX/  this  paper  is  mentioned  here  to  emphasize  the  oeneral 
trend  of  thesis  work  oone  in  support  of  the  laboratory's 


refresh  graphics  devices.  Furthermore#  recommendations  in  a 


later  chaoter  of  this  oaper  soecificailv  address  the 
integration  of  SSUNIX  into  the  mul t i processor  environment. 

8.  GENERAL  SYSTEM  PROPOSAL 

As  indicated  in  the  previous  section#  the  specific 
system  prooosed  by  this  thesis  was  designed  primarily  to 
perform  data  space  alignment  in  a shared  memory  area  for 
resident  signal  processing  and  refresh  araphics  processes. 
However#  the  actual  modifications  to  UNIX  Mere  designed  to 
offer  more  general  applications.  SUNIX  was  implemented  as  a 
general  ourpose  operating  system  with  segmented  memory 
management.  The  differences  between  UNIX  and  SUNIX  are 
transparent  to  the  User.  SSUNIX  provides  the  ability  to 
align  a process's  data  space  within  any  given  area  of  User 
memory  space.  Location  and  size  of  this  memory  region# 
which  was  intended  to  correspond  to  shared  memory  assets# 
can  be  specified  at  system  generation  time.  The  limitations 
of  UNIX  in  a system  configured  with  devices  which  demand 
heavy  DMA  and  real-time  system  support  are  discussed.  The 
general  concepts  behind  the  design  of  SUNIX  and  SSUNIX  are 

also  presented. 

/ 

1.  Limitations  of  the  Present  System 
a.  bus  A 1 | ocat i on 

As  shown  in  Figure  1#  all  POP-ll/SO  components 
and  peripherals  connect  to  and  communicate  with  each  other 
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over  a high-sceed#  bidirectional#  asynchronous  bus  known  as 


the  UNI8US  (31.  Devices  gain  access  to  the  UNIBUS  via  an 
arbitration  unit.  This  unit  grants  bus  mastershio  based  on 
a multilevel  priority  scheme.  Each  device  on  the  UNlbUS  is 
assigned  a hardwired  priority  which  is  recognized  by  the 
arbiter.  A device  is  granted  immediate  mastership  when  a 
request  is  made  and  no  device  of  equal  or  higher  priority 
has  control.  DMA  requests  from  peripheral  devices  have 
highest  priority.  The  central  processing  unit  (CPU)  has  the 
capability  to  control  or  release  the  bus  by  varyinq  its  own 
priority  level.  This  makes  it  possible  for  devices  to 
access  main  memorv  with  almost  no  processor  intervention. 

Devices  which  require  a larqe  amount  of  DMA 
place  heavy  demands  on  the  UNIBUS.  A oroblem  arises  in  a 
multiprogramming  environment  when  a process  is  running  at  a 
high  scheduling  oriority  (as  with  real-time  processes)#  and 
also  reauires  high  priority  and  heavy  bus  utilization  for 
DMA.  In  this  case#  all  other  processes  are  essentially 
suspended  since  thev  cannot  gain  access  to  the  UNIBUS. 
Refresh  graphics  devices  reouire  heavy  bus  utilization  for 
processing  the  display  list.  In  the  case  of  the  VG  devices 
in  the  laboratory,  the  display  list#  located  in  the  resident 
graohics  process's  data  space#  must  be  processed  every  one- 
fortieth  of  a second.  It  is  thus  necessary  to  lock  the 
active  display  list  in  memory.  If  the  list  were  not  in 
memory  'at  the  time  of  a refresh  cycle  an  inordinate  delay 
would  occur#  causing  the  display  to  flicker  or  fade. 

As  noted  previously#  duel-oorted  memory  was 
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conceived  as  a solution  to  these  problems.  With  the 
peripheral  processors  each  assigned  a separate  bus  attached 
to  memory  ports  ooposite  the  main  processor.  interference 
during  DMA  could  be  virtually  eliminated.  The  problem  which 
remained  was  t he- al 1 ocat i on  of  a process's  data  space  to  one 
of  the  shared  memory  areas.  Visco's  design  attempted  to 
solve  this  problem  specifically  for  VG  processes.  SSUNIX 
was  designed  to  solve  the  problem  for  more  general 
appl icat ions. 

b.  Memory  Allocation  Scheme 

In  UNIX#  while  the  processor  is  executing  in 
behalf  of  a process#  its  image  must  reside  in  main  memory  as 
a single  contiguous  unit.  Unless  swapping  is  necessary#  the 
image  remains  in  memory  during  the  execution  of  other 
processes.  When  the  CPU  is  executing  a process#  MMU 
registers  are  loaded  so  the  process  can  access  only  its  own 


image  and#  if  applicable#  a text  segment  shared  with  other 


processes. 

The  memory  allocation  scheme  used  in  UNIX  is 
based  on  a " f i rst-f  i t * algorithm.  That  is#  the  Process 
image  is  allocated  space  in  the  first  free  area  in  the 
system's  free-list  which  can  accomodate  it.  With  this 
scheme#  selective  allocation  and  alignment  of  memory  space 
in  a particular  region  of  memory  is  impossible.  This  is 
unsatisfactory  in  a system  configured  with  multiported 
memory.  As  an  example#  the  Computer  Signal  Processors 


Incorporated  CSP  125  controller  can  access  only  that  portion 
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of  memory  indicated  in  Figure  1.  Any  process  that 
communicates  with  the  CSP  125  must  have  its  data  space 
located  in  that  area  of  memory. 

2.  Genera)  Features  of  the  Proposed  System 


a.  Segmentation 

The  initial  decision  that  had  to  be  made  to 
solve  the  problems  stated  above  was:  what  type  of  memory 
management  modifications  to  UNIX  were  required  to  provide  a 
general  and  efficient  operating  system  which  would  support 
alignment  of  a resident  process's  data  space  in  a oiven 
region  of  memory.  The  segmented  memory  manager  designed  by 
Emery  (SUNIX)  was  chosen  as  a basis  for  the  intended 
modifications.  Segmentation  had  several  advantages  which 
made  this  choice  attractive.  Process  imaoes  in  UNIX  consist 
of  several  logically  independent  segments.  Although  not 
managed  separately#  this  natural  division  provides  an 
appealing  basis  for  segmentation.  Modifications  to  the 
existing  memory  management  routines  to  implement  SUNIX  were 
st rai qht f orward  and  relatively  simple. 

The  segmentation  chosen  also  proved  to  be  an 
efficient  way  to  handle  dynamic  changes  in  the  size  of  User 
data  and  stack  areas.  In  UNIX,  when  the  User  space  grows 


beyond  the  available  contiauous  memory  soace,  it  is 
necessary  to  reestablish  the  entire  process  image  in  main 
memory.  This  is  accomplished  by  cooyino  the  process  image 
to  a new  free  area  of  sufficient  size.  Since  there  is  no 
hardware  facility  on  the  P0P-11/50  for  a "block  move"  in 


memory#  this  Is  a major  source  of  memory  management 
overhead.  The  cost  of  the  copy  operation  is  about  10 
micro-seconds  per  word  C41 . This  figure  is  even  worse  if 
space  is  not  readily  available  for  the  larger  image  and 
other  processes  have  to  swapped  out  to  make  room.  In  SUNIX 
the  User's  data  and  stack  are  managed  independently.  Growth 
of  either  area  reauires  reestablishing  only  that  segment  in 
memory.  Total  overhead  due  to  dynamic  in-core  expansion  is. 
therefore,  reduced. 

b.  Data  Space  Alignment 

After  decidina  on  SUNIX  as  the  operating  system 
which  would  best  serve  the  purposes  of  this  thesis,  a method 
of  positioning  a process's  data  space  at  a particular 
location  in  main  memory  had  to  be ‘devel oped.  Detailed 
analysis  of  the  memory  management  routines  in  both  SUNIX  and 
UNIX  was  necessary  before  Proceeding.  The  method  chosen, 
and  implemented  in  SSUNIX.  was  a direct  extension  of  SUNIX. 
No  modification  to  the  segmentation  scheme  was  necessary, 
and  only  minor  modi f i cat i ons  to  the  other  memory  management 
routines  were  required.  The  aeneral  aporoach  taken  was  to 
implement  the  necessary  changes  by  adding  several  system 
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routines  to  acquire,  allocate,  and  release  a shared  memory 
asset.  System  calls  were  imolemented  to  perform  these 
functions  for  processes  requiring  shared  memory. 

Providing  system  protection  was  a Secondary  goal 
in  the  design  of  a memory  manager  for  SSUNIX.  The  concept 
of  system  protection  implies  that  inadvertent  destruction  of 
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vital  process  information*  particularly  the  process  control 


information  used  by  the  operating  sytem*  will  not  occur. 
Address  range  limitations  of  the  peripheral  processors 
prevent  their  manipulation  of  data  in  memory  locations 
outside  of  the  shared  region.  SSUN1X  allows  only  the  data 
space  of  processes  communicating  with  these  devices  in  this 
region.  The  combination  of  these  two  features  provided  the 
system  protection  desired. 
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III.  THE  UNIX  OPERATING  SYSTEM 


Thus  far  in  this  thesis#  the  UNIX  operating  system  has 
been  discussed  in  general  terms.  This  chapter  provides  a 
more  detailed  discussion  of  the  concepts  of  system 
operation.  Concepts  in  the  design  of  the  memory  managers  in 
UNIX#  SUNIX  and  SSUNIX  are  also  presented.  This  chapter 
provides  the  background  necessary  for  understanding  the 
modifications  made  to  UNIX  to  implement  SUNIX  and  SSUNIX. 

A.  CONCEPTS  OF  OPERATION 

UNIX  171  is  a terminal  oriented#  time-sharing  operating 
system  developed  at  Bell  Laboratories  for  the  Digital 
Equipment  Corporation  (DEC)  PDP-11  family  of  minicomputers. 
Most  of  the  source  code  for  UNIX  is  written  in  "C"  IP] # a 
high  level  systems  implementation  language.  The  remainder 
of  the  source  is  written  in  "as"  U01#  a Bell  Laboratories 
variant  of  PDP-11  assembly  language. 

Multi-tasking  in  UNIX  is  performed  on  a basic  unit  of 
work  called  the  process.  A orocess  consists  of  system 
control  information#  executable  instructions#  and  data. 

rthen  the  operatina  system  is  "boot st rapoed"  into  memory  at 

. 

system  initiation  time#  it  "handcrafts"  its  first  two 
processes.  Process  0 is  the  master  control  process  (the 


Process  1 initializes  the  operating  environment  for  other 
processes  in  such  a manner  that  all  subsequent  processes  are 
its  descendents.  All  other  processes  are  executions  of 


program  files  from  the  UNIX  file  system. 

Descendents  of  a process  are  created  by  execution  of  the 
"fork"  system  call.  This  svstem  call  replicates  the  calling 
process^  creating  a new  (child)  process  that  has  a uniaue 
process  number.  The  original  process'  called  the  parent' 
can  continue  execution  or  temporarily  susoena  itself  until 
the  child  terminates.  A child  process  may  either  continue 
execution  of  the  same  program  or  invoke  a new  program  into 
execution.  New  processes  are  invoked  by  "exec"'  a system 
call  that  "overlays"  the  calling  process  with  an  executable 
file  from  the  file  system.  Child  processes  may  also  spawn 
children  of  their  own.  when  any  child  completes  execution' 
it  terminates  by  means  of  the  "exit"  system  call.  "Exit" 


terminal  and  oromots  for  another  log  in. 

From  the  User's  point  of  view#  the  most  important  role 
of  UNIX  is  to  provide  a file  system  £73 . There  are 
basically  three  kinds  of  files  suoported  by  the  system: 
ordinary  disk  files/  directories/  and  special  files. 
Ordinary  files  contain  whatever  information  the  User  places 
on  it.  Source  erograms/  object  modules  generated  by 
compilers  or  assemblers/  and  pure  text  are  examples  of 
ordinary  files.  Directories  orovide  a maoping  of  orainarv 
file  names  to  the  files  themselves/  thereby  inducing  a 
structure  on  the  file  system.  All  files  in  the  system  may 
be  located  by  tracing  a path  from  the  "root"  directory  to 
the  desired  file.  User  interface  to  each  input/ouput  (I/O) 
device  supported  by  the  system  is  throuqh  a dev i ce*soec i f i c 
special  file.  With  this  scheme/  I/O  devices  can  be  treated 
as  ordi nary  files. 


B.  MEMORY  MANAGER  DESIGN 


The  UNIX  memory  manager  is/  in  concept/  a relocatable 
partitioned  memory  manager  with  swaoping  ana  limited 
segmentation.  While  the  processor  is  executing  in  behalf  of 
a process/  the  process  image  must  reside  in  a contiguous 
region  in  main  memory.  As  already  explained/  during  the 
execution  of  other  processes/  a process  may  remain  in  memory 
unless  scheduling  of  a hiaher  priority  process  forces  it  to 
be  swapped  out  (copied)  to  the  swap  device.  UNIX  processes 


art  logically  divided  into  three  parts:  the  UVECTOR,  the 


U**»r  data  space#  and  the  User  processor  stack.  If  a process 
requires  use  of  shared  text,  its  data  space  contains  only 
data.  Shared  text  is  managed  separately. 

The  UVECTOR  contains  all  process  status  information 
required  by  UNIX  while  the  process  is  resident  in  core. 
Other  process  status  information#  which  must  remain 
addressable  throughout  the  life  of  the  process#  is  contained 
in  a system  control  block  called  a PROC.  In  the  case  of 
shared  text#  the  PROC  contains  a pointer  to  yet  another 
system  control  block  called  a TEXT.  This  block  contains  all 
information  necessary  to  control  the  sharing  of  a text 
segment  oy  one  or  more  processes.  Shared  text#  if  reauired# 
is  established  in  memory  independently  of  the  processes 
which  are  sharing  it.  If  a process  shares  text#  "exec" 
checks  to  see  if  a copy  of  the  text  segment  is  already 
available  in  the  system.  If  it  is  not#  a copy  is  created. 

User  address  space  of  a text -shari no  process  may  be 
created  with  separate  instruction  space  (I-space)  ana  aata 
soace  (D-space)»  or  with  combined  I-soace  and  D-soace.  User 
address  space  for  non-sharing  processes  is  established  with 
combined  instruction  and  data  soaces.  If  the  I-soace  and 
D-soace  of  a process  are  combined#  there  is  no 
differentiation  between  instructions  and  data.  The  file 
type  [7]  of  an  executable  file  is  used  by  "exec"  to 
establish  a separation  flag  in  the  UVECTOR.  This  flag  is 
used  to  control  the  method  by  which  the  address  space  for  a 
text  sharing  orocess  is  established.  The  shared  text 
segment  of  a process  with'  separate  address  soaces  is 
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addressed  beginning  at  User  l-space  address  0;  data  is 
addressed  beginning  at  User  O-soace  address  0.  If  a Process 
with  combined  address  spaces  Has  shared  text*  the  text 
segment  is  addressable  beginning  at  address  0 in  both  I- 
soace  and  D-soace.  Its  data  is  addressed  in  both  I-space 
and  D-space#  beginning  at  the  first  4K  word  boundary  above 
the  shared  text  segment.  For  processes  without  shared  text# 
the  text  is  addressed  beginning  at  address  0 in  the  combined 
1-soace  and  O-soace*  and  its  data  is  addressed  beqinninq  a» 
the  first  word  boundary  above  the  text.  The  User’s 
processor  stack  is  addressed  extending  downwara  from  the 
highest  address  in  0-space  or  combined  I-space  and  0-space. 

PDP-11/50  oaqe  address  registers  (PARs)  and  page 
descriptor  registers  (PDFs)  are  loaded  when  a proc»ss  image 
is  brought  into  memory  or  its  ' .address  soace  is 
reestablished.  PARs  are  used  by  the  *MU  to  translate 
virtual  addresses  to  physical  memory  addresses.  PDRs  are 
used  to  describe  a set  of  attributes  about  a resident 
process's  pages.  A page  in  UNIX  can  be  thought  of  as  a 
partition  of  a process  imaae  which  can  be  up  to  4K  words  in 
length.  Access  control  specified  in  the  PDRs  is  read  only 
for  shared  text  pages  and  read-write  for  all  other  naoes. 

User  data  soace  may  vary  dynamically  if  required  aurinq 
execution  of  a orocess.  A system  call*  "break"#  is  provided 
in  UNIX  to  alter  the  size  of  the  data  area.  Additionally# 
the  size  of  a process  image  may  be  increased  ov  dynamic 
growth  of  the  User  processor  stack.  When  this  occurs#  the 
svstem  automatically  increases  the  amount  of  scace  provided 
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for  the  process.  In  both  of  these  cases#  UNIX,  must 
reestablish  the  entire  process  image  in  main  memory.  As 
mentioned  oreviously#  one  of  the  primary  benefits  of 
segmentation  is  indicated  here.  SUNIX  and  SSUNIX  reauire 
that  only  the  segment  which  changes  size  be  reestablished. 


1.  Segmentation 

Segmentation  of  shared  text  is  already  well 
supported  in  UNIX.  SUNIX  and  SSUNIX  further  divide  process 
images  into  the  three  natural  segments  mentioned  before: 
UVECTOR#  data  space  (including  non-shared  text)#  and  User 
stack.  Allocation  of  memory  space  for  a process  is 
accomplished  by  separately  establishing  each  segment  in  a 
free  area  large  enough  for  it.  Contiguous  allocation  in 
memory  is  possible#  but  not  required.  Swao  space  for  a 
process  is  still  allocated  in  a contiguous  oartition  on  the 
system's  swao  device.  However,  due  to  the  separation  of 
segments  in  main  memory,  up  to  three  copy  operations  are 
required  each  time  a process  is  swapped  to  or  from  the  swao 
device.  In  UNIX,  only  one  copy  operation  is  required. 
Thus,  there  is  an  increase  in  svstem  overheao  with  segmented 
memory  management.  There  is,  however#  a compensating 
advantage  to  segmentation:  a reduction  of  overheao  (segment 
copying)  results  from  independent  management  of  data  and 
stack  segments  if  dynamic  growth  of  one  of  these  segments  is 
requi red. 
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2.  Allocation  of  Memory  Space 

The  basic  .quantum  of  memory  space  in  UNIX  is  a 
64-byte  area  called  a block.  This  is  the  smallest  Quantum 
supoorted  by  the  PDP-11/50  MMU.  Memory  space  for  each 
process  is  assigned  from  a free  memory  mao  maintained  by  the 
operating  system.  This  map*  which  is  establisheo  at  system 
initiation  time  based  on  ohysical  memory  configuration# 
contains  the  base  address  and  size  (in  blocks)  of  each 
unallocated  area  of  User  memory  space.  Addresses  in  the  map 
are  increasing  in  order  and  represent  the  physical  block 
number  of  the  free  area  to  which  they  refer.  The  operatinq 
system  is  established  beginning  at  ohysical  address  0.  User 
memory  space  begins  at  the  first  block  boundary  above  the 
system  code. 

Maintenance  of  the  free  memory  mao  is  performed  by 
the  memory  management  primitives  "malice"  and  "mfree". 
These  system  routines  are  also  generalized  to  perform 
maintenance  of  all  other  system  free  maps*  for  example*  the 
swao  mao*  and  the  shared  memory  maps  (described  later)  in 
SSUWIX.  The  function  of  "malloc"  is  to  locate  an  area  of 
given  size  in  the  given  map#  update  the  map  to  reflect  the 
allocation  of  the  area#  and  then  return  the  physical  block 
number  of  the  allocated  area  to  the  callinq  routine.  The 
algorithm  used  in  "malloc"  is  "first-fit".  That  is#  the 
free  mao  is  searched  seauent i a 1 1 y # beainninq  with  the  first 
entry#  until  an  area  of  sufficient  size  to  satisfy  me 
request  is  found.  If  the  requested  space  is  not  available* 
a zero  value  is  returned  to  the  caller.  The  ♦unction  of 


"mfree"  is  to  free  the  area  specified  by  the  eallinq 
routine.  The  region  specified  is  sorted  back  int-o  the  free 
map  and  combined  on  one  or  both  ends  if  possible.  In  UNIX* 
processes  are  allocated  space  based  on  the  size  of  the 
entire  process  image.  In  SUNIX  and  SSUNIX,  each  segment  of 
a process  is  allocated  memory  space  separately  based  on  the 
segment  size. 

3.  Multiported  Memory 

Regions  of  multiported  memory  are  often  oesirable  to 
support  peripheral  devices  which  have  uniaue  DMA 
requirements.  Examoles  are  devices  which  have  hardware 
address  ranqe  limitations  or  require  real-time  memory 
access.  Specific  aoplieations  of  multioorted  memory  in  the 
Signal  Processing  and  Disolay  Laboratory  have  already  been 
di scussed. 

To  support  multiported  memory,  the  operat'no  svstem 
must  be  able  to  align  a orocess  or  process  segment  in  the 
multiported  memory  reaion.  UNIX  does  not  have  this 
capabi lity.  As  explained  in  the  orevious  section,  "mal 1 oc " 
assigns  memory  space  from  the  User  free  map  cased  on  a 
"first-fit"  algorithm.  With  this  alaorithm,  alignment 
within  a specified  region  of  memory  would  he  purely 
coincidental.  Furthermore*  since  DMA  by  a peripheral  device 
to  UVECTGR  or  stack  addresses  violates  system  security,  only 
the  data  segment  is  claced  in  the  multiported  reaion.  lhis 
implies  that  segmentation  is  a desirable  memory  management 
scheme  in  a system  configured  with  multioorted  memory.  For 


this  reason,  SUNIX  was  chosen  as  the  basis  for  development 
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of  multiported  memory  system  support*  Although  there  was  no 
provision  for  data  segment  alignment  in  SUNIX,  the  method  of 
process  segmentation  directly  suoported  the  design  effort 
undertaken  by  this  author* 

In  order  to  investigate  multioorted  memory 
applications  in  UNIX,  a shared-segmented  memory  manaaer 
(SSUNlX)  was  designed  and  implemented.  SSUNIX  provides  tne 
capability  to  align  a calling  process's  data  segment  in  a 
shared  memory  region,  and  to  ensure  system  projection  by 
clearing  all  other  processes  from  that  region,  ^ree  memory 
maps  were  established  and  maintained  for  each  scared  core 
area.  Processes  recuested  the  shared  memory  asset  via  a 
system  call  ( "get shr " ) . A system  routine  was  designed  which 
Checked  the  User  free  memory  map  to  determine  if  the 
requested  region  was  free.  If  the  area  was  free,  it  was 
removed  from  the  User  free  memory  mao  and  the  data  space  of 
the  calling  User  process  was  moved  to  the  shared  region. 
The  "malloc"  system  call  was  used  to  allocate  soace  for  the 
data  segment  in  the  requested  shared  reaion.  If  the  area 
was  in  use  by  another  memory-shar i ng  process,  the  data 
segment  of  the  calling  process  was  simply  allocated  in  fhe 
shared  memory  map  and  then  moved  to  the  region.  If  the  area 
was  in  use  bv  other  non-memory-shar i ng  processes,  these 
processes  were  swapped  out  of  memory  until  t**e  area  was 
clear.  The  data  segment  of  the  callinq  User  process  was 
then  allocated  in  the  shared  memory  map  ana  -nvea  to  the 
region. 
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In  each  o * the  above  cases#  after  a shared  memory 
region  had  bean  acauired  for  a memory-sharing  orocess#  non- 
memory-sharing processes  were  not  allocated  space  within  the 


bounds  of  the  shared  region.  Additionally#  the  calling 
process  was  locked  into  memory  so  it  would  not  be  swapped 
out  of  the  area.  Another  system  call  ("freeshr")  was 
implemented  to  release  a oroeess's  shared  memory  asset  and 
unlock  the  process  image.  This  system  call  updated  the 
shared  memory  map.  If  no  other  memory-sharing  orocesses 
remained  in  the  region#  the  entire  shared  memory  area  was 
returned  to  the  User  free  map. 


IV.  MODIFICATIONS  TO  UNIX 


A.  GENERAL 


Modification*  to  the  UNIX  operating  system  to  Produce 
SUNIX  were  performed  by  Emery  [4J  in  mid-1976.  The  approach 
taken  in  the  desiqn  was  to  make  the  general  structure  of 
memory  management  familiar  to  those  who  understood  the 
structure  of  UNIX.  This  aporoach  led  to  a we l I -des i gned 
operating  system  which  readily  supported  further 


modifications  and  debugging.  However,  due  to  greater 
emphasis  on  the  completion  and  testing  of  a oartitioned 
segmented  memory  manager  (PSUNIX),  SUNIX  was  not  implemented 
at  that  time.  Final  implementation  and  testing  of  SUNIX  was 
a primary  goal  of  this  thesis  project.  SSUNIX  was  to  be  a 
direct  extension  of  SUNIX.  For  this  reason,  modifications 


to  UNIX  required  to  implement  SSUNIX  encompass  those  made 
for  SUNIX. 


The  changes  necessary  to  implement  process  segmentation 
with  data  segment  alignment  affected  five  general  areas: 

1.  Control  Blocks 

2.  Memory  Manaaement 

3.  Swap  Space  Allocation 

4.  Shared  Memory  Allocation 

5.  Supoort  Proarams 
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Each  of  those  areas  is  discussed  in  a subsequent  section  of 
this  chapter.  The  apoendices  to  this  thesis  orovide  further 
documentation.  Information  on  control  block  modi f icat i ons 
is  found  in  Appendix  A.  Memory  management  and  shared  core 
allocation  modifications  are  described  in  Aopendix  8. 

8.  CONTROL  BLOCKS 

UNIX  control  blocks  are  data  structures  used  by  the 
operating  system  to  maintain  information  vital  to  system 
control.  The  only  control  block  modification  required  to 
supoort  process  segmentation  was  the  PROC.  A list 
containing  a PROC  for  each  active  process  is  maintained  bv 
the  system.  In  UNIX,  a PROC  contains  the  blocx  address  of 
the  UVECTOR  and  the  sire  of  the  process  image  (which  does 
not  include  shared  text).  In  SUNIX  and  SSUNIX,  a PROC 
contains  the  block  address  of  each  of  the  process  segments 
and  the  sires  of  the  data  and  stack  segments. 

Several  new  control  blocks  were  added  to  implement  data 
segment  alignment  within  a shared  core  area.  Sn^fcM  defines 
the  upper  and  lower  bounds  of  each  shared  memory  region. 
Svstem  shared  core  conf  i gurat  i on  changes  reauire  modifyina 
the  entries  in  this  structure.  SHMEN  is  used  at  svstem 
initiation  time  to  initialize  two  other  shared  memory 
control  blocks.  A SHARE  contains  information  about  a 
particular  shared-memory  asset.  The  high  and  low  bounds  of 
the  region,  a flaa  indicating  whether  or  not  the  region  is 
in  use  by  another  memory-shar i no  process,  and  another  flaa 


used  by  "malloc"  are  maintained  here.  A SHRMAP  is  a 
structure  which  contains  a free  memory  map  for  each  of  the 
shared  regions.  The  maos  in  SHRMAP  were  configurea  exactly 
like  the  other  system  free  maps  so  they  could  be  maintained 
by  "malloc"  and  "mfree". 


C.  MEMORY  MANAGEMENT  MODIFICATIONS 


I §' 

I 

| 

I 


Adapting  the  existing  UNIX  memory  management  routines  to 
perform  process  segmentation  was  a at ra i ght f orwaro  problem: 
in  each  routine  that  eealt  with  a process  image#  tne  orocess 
image  was  managed  as  three  independent  seqments  instead  of  a 
single  entity.  Although  simply  stated#  solving  this  problem 
required  many  hours  of  f am i 1 i a r i zat i on  with  existing  UNIX 
concepts#  and  modifying  several  hundred  lines  of  source 
code.  Details  of  these  modifications  are  not  included  here# 
but  are  contained  in  Appendix  B.  Copies  of  system  source 


code  cannot  be  included  in  this  thesis  due  to  UNIX  non- 
disclosure agreements.  However#  authorized  UNIX  User's  mav 
acquire  machine-readable  copies  by  contacting  the  Naval 


Postgraduate  School. 


D.  SWAP  SPACE  ALLOCATION  MODIFICATIONS 
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Swap  space  is  allocated  to  a orocess  when  it  must  be 
swaooed  out  of  memory#  and  freed  when  the  process  returns  to 
memory.  A mao  of  free  space  on  the  system's  swap  device  is 
maintained  by  "malloc"  and  "mfree".  The  svstem  routine 
"swap"  is  used  to  transfer  data  between  memory  and  the  swap 


device*  SUNTX  and  SSUNIX  processes  consist  of  three 
segments  that  are  independently  established  in  main  memory. 
Moving  a process  image  to  the  swao  device  requires  a "swap" 
operation  for  each  segment.  Also*  when  shared  text  must  De 
established,  an  additional  "swap"  operation  is  involved. 
Actual  space  on  the  swao  device  is  allocated  in  a contiguous 
block.  The  disk  address  of  the  process  is  the  address  of 
the  UVECTOtt.  Data  (if  any)  and  stack  are  located 
immediately  following  the  UVECTOR.  Shared  text  is 
separately  established.  and  retains  it  swap  space  until 
there  are  no  longer  any  live  processes  which  reauire  it. 


E.  SHARED  MEMORY  ALLOCATION  MODIFICATIONS 

The  basic  ideas  underlying  the  design  of  a shared- 
segmented  memory  manager  for  UNIX  (SSUNIX)  were  presented  in 
Chapter  III.  Actual  design  work  was  started  after  SUMIX  was 
implemented  and  had  demonstrated  satisfactory  performance. 


The  approach  taken  in  the  development  of  SSUNIX  was  to  add 
several  system  level  routines  to  perform  the  sharea  memory 
management  functions#  ana  thus  modify  existing  SuNix  code  as 
little  as  possible.  Three  new  system  routines  were  added: 
"ckmao"#  to  check  the  User  free  memory  map#  "shalloc"#  to 
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Appendix  B. 

The  new  procedure  "ekmao*  was  the  basic  primitive  used 
for  shared  core  allocation.  Its  function  was  twofold?  check 
the  User  free  memory  mao  to  determine  if  an  area  between  a 
given  high  and  low  block  address  was  free#  and  then#  if  t-he 
area  was  free#  remove  it  from  the  free  mao.  The  design  of 
this  procedure  provided  an  interesting  challenge.  Once  it 
was  determined  that  the  area  was  free#  several  boundary 
alignment  conditions  had  to  be  considered  in  order  to  remove 
it  from  the  free  memory  mao.  The  procedure  "shalloc" 
performed  the  actual  allocation  and  assignment  of  a 
processes  data  segment  to  the  requested  shared  core  area. 
It  also  locked  the  process  imsge  in  memory.  The  alaorithm 
implemented  was  described  in  the  orevious  chaoter.  In  order 
to  prevent  allocation  of  another  orocess  within  the  shared 
core  region  durina  the  shared  core  acouisition  by  "shalloc"# 
a slight  modification  to  the  memory  management  primitive 
"malloc"  was  reauired.  * orocess's  shared  memory  asset  was 
freed  by  "shfree".  In  addition  to  the  system  call 
interface#  this  routine  was  called  from  the  "exit"  procedure 
to  ensure  that  a orocess's  shared  core  was  released  at 
process  termination. 

Other  modifications  to  SUNTX  included:  "main"#  to 
establish  shared  core  regions  and  initialire  their 
resoective  control  blocks;  and  "sysent"#  to  provide  system 
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entry  points  for  the  system  cells  "getshr"  and  "freeshr". 
The  source  code  reouired  to  build  both  SUNIX  and  SSUNIX  can 
be  found  in  the  directory  /usr/sys. suni x on  the  display 


processor's  file  system. 


F.  SUPPORT  PROGRAM  MODIFICATIONS 


One  supoort  proaram  modification  was  reouired  for  SUNIX 
and  SSUNIX.  The  She?l  command  "os"  fill  disolays  certain 
information  about  active  process  status.  It  uses  the  PROC 
list  to  acquire  this  information  for  display  at  the  User's 
terminal.  Since  the  Structure  of  the  PROC  was  modified  to 
supoort  process  segment  at i on # certain  variables  used  by  "os" 
were  invalidated.  In  particular#  the  address  and  size  of  a 
process  image  in  UNIX  were  described  in  two  variables  in  the 
PROC.  In  SUNIX  and  SSUNIX#  five  variables  were  required: 
UVECTOR  address  Cits  size  is  fixed  at  .5K  words)#  data 
segment  address#  data  segment  size#  stack  segment  address# 
and  stack  segment  size.  To  retain  the  display  format  used 
by  "ps"#  it  was  decided  that  all  five  of  these  attributes 
would  not  be  cresented.  Since  the  User  is  normally 
concerned  with  only  his  data  segment's  address  and  size# 
these  values  were  substituted  for  the  existinq  values  in 
"os".  The  revised  version  of  this  routine  can  be  found  in 
/usr/sys . sun i x on  the  display  processor's  file  system.  The 
object  version  cf  "os"  found  in  /bin  must  be  replaced  with 
the  revised  object  during  SUNIX  and  SSUNIX  operation. 
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V.  EVALUATION  OF  PERFORMANCE 


A.  OVERVIEW 

As  stated  throughout  this  report#  completion  and  testinq 
of  SUN  IX  was  an  integral  part  of  this  thesis  and  a 
prerequisite  for  the  development  of  SSUNIX.  A severe 
problem  with  the  SUNIX  memory  manager  had  prevented  its 
final  implementation.  This  problem  manifested  itself  in  an 
inability  to  assemble  certain  programs.  Since  the  assembler 
is  used  during  a oass  of  the  "C*  compiler#  compilations  were 
also  affected.  Several  weeks  at  the  outset  o*  this  thesis 
project  were  reauired  to  become  familiar  with#  debug  and 
test  SUNIX.  Once  familiar  with  the  concepts  of  system 
organization  and  memory  management#  Emery's  design  readily 
supported  the  debugging  effort  at  hand.  Tne  problem  was 
eventually  found  and  corrected  in  the  memory  management 
routine  "exec".  Development#  implementation  and  testing  of 
SSUNIX  followed.  Performance  of  SUNIX  and  SSUNIX  was 
evaluated  in  relation  to  UNIX.  Additionally#  tests  were 
conducted  which  demonstrated  the  capability  of  SSUNIX  to 
perform  data  seqment  allocation  and  deallocation  of  shared 
core. 
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8.  COMPARISON  WITH  UNIX 


The  method  chosen  to  compare  oerformance  of  UNIX#  SUNIX 
and  SSUNIX  was  to  use  the  elaosed  execution  time  of  a 
standard  stream  of  processes  (benchmarks)  • A series  of 
benchmarks  was  run  to  determine  relative  oerformance  under  a 
variety  of  operating  conditions.  Available  User  memory  was 
the  variable  used  to  establish  these  conditions.  Two 
benchmarks  were  used:  a monoprogrammi ng  benchmark#  BENCH1J 
and  a multiprogramming  benchmark#  BENCH2.  These  benchmarks 
are  essentially  identical  to  those  used  by  Emery  in  his 
testing  of  PSUNIX.  Roth  BENCH1  and  BENCH2  contain  the  same 
sequence  of  UNIX  commands.  These  commands  are  documented  in 
Ref.  11.  APPENDIX  C contains  benchmark  listings.  The 
computer  system  used  for  the  tests  was  the  multiuser  side  of 
the  laboratory  con f i gu ra t i on  shown  in  Figure  1.  A single- 
user  environment  was  established  with  only  the  console  on- 
line. The  ourpose  of  this  was  to  prevent  the  introduction 
of  an  added  variable  in  benchmark  performance  due  to 
processes  aenerated  by  other  Users  on  the  system.  The  swao 
space  and  file  system  used  were  located  on  RP05  disk  units 
13)  . 

Table  I presents  the  results  of  benchmark  tests  for 
UNIX#  SUNIX  and  SSUNTX.  Available  User  memorv  space  was 
varied  to  evaluate  oerformance  over  a wide  range  of  svstem 
configurations.  Timino  data  was  obtained  by  using  the  UNIX 
"time"  command  (113.  Processes  run  under  control  of  "time" 
are  clocked  bv  samol ina  processor  state  at  the  rate  of  60 


Hz.  "Real*  time  reflects  the  total  elapsed  time  for  the 
process  and  is  reported  to  the  nearest  second.  "User"  time 
is  the  time  spent  in  the  User  state  (ie.  executing  the 
User's  program  instructions)  and  is  reoorted  to  the  nearest 
tenth  of  a second.  "Sys"  time  is  the  time  spent  during  the 
execution  of  operating  system  supervisory  instructions  and 
is  reported  to  the  nearest  tenth  of  a second.  The 
difference  between  "real"  time  and  the  sum  of  "user"  and 
"sys"  times  indicates  the  amount  of  processor  idle  time. 
Idle  time  generally  reflects  the  amount  of  time  spent  on 
asynchronous  I/O  operations. 

In  addi tion  to  benchmark  testina  in  a single-user 
configuration#  SUNTX  was  run  for  a full  day  of  multiuser 
program  development.  The  system  was  fullv  configured  (Fig. 
1)  and  moderate  to  heavy  system  utilization  was  noted. 


Svstem  Users  were 

asked 

to  report  any 

problems 

to 

laboratory  staff. 

No 

system  f ai lures 

occurred 

and 

problems  were  reported.  This  test  provided  an  excellent 
indication  of  prooer  system  ooerat ion  as  well  as  the 
transparency  of  the  memory  management  method  to  svstem 
Users . 

C.  SHARED  MEMORY  ALLOCATION 

Testing  of  data  segment  allocation  to  shared  core  was 
performed  on  the  display  processor.  The  system  was 
configured  with  a single  terminal  and  the  svstem  console. 
Swap  space  and  the  file  system  were  maintained  on  PP05  disk 


units.  To  demonstrate  the  oerformance  of  SSUNIX#  it  was 
necessary  to  develop  a method  for  displaying  certain 
relavent  system  information.  Three  items  were  required:  the 
location  of  a process's  data  segment  in  memory#  the  state  of 
the  User  free  memory  mao#  and  the  state  of  each  of  the 
shared  memory  maps.  This  data  best  indicated  the  shared 
memory  a I I ocat i on/dea 1 I ocat i on  Process.  A system  call 
("shtest")  was  developed  to  display  this  information  at  the 
display  processor's  console.  Several  test  programs  which 
included  shared  core  allocation  requests  ("getshr")  and 
shared  core  deallocation  requests  ("freeshr")  in  various 
sequences  were  developed.  "Shtest"  was  included  in  these 
programs  to  display  the  required  information  after  each 
shared  core  ooeration.  This  approach  proved  invaluable  in 
the  debugging  and  refinement  of  SSUNIX. 

0.  ANALYSIS  OF  RESULTS 

The  results  shown  in  Table  I clearly  indicate  that  the 
performance  of  UNIX,  SUNIX  and  SSUNIX  are  nearly  identical. 
No  statistical  analysis  was  performed  on  these  results#  but 
earlier  work  16]  indicates  that  the  sampled  data  may  have  a 
standard  deviation  of  as  much  as  8 percent  on  identical 
benchmarks  run  several  times  on  the  same  system.  System 
supervisory  times  ("STS")  under  SUNIX  and  SSUNIX  were  found 
to  be  slightly  better  than  UNIX  in  some  cases.  This  is  a 
surprising  result  in  linht  of  the  more  complex  memory 
management  function  with  process  seament at i on . The 


disadvantage  related  to  increased  sweeping  overhead  did  not 
appear  to  degrade  overall  system  performance.  A probable 
explanation  for  this  result  is  an  offsetting  performance 
improvement  due  to  independent  dynamic  growth  of  data  and 
stack  segments.  These  factors  were  discussed  in  Chapter 
III.  SSUNIX's  performance  in  a multiported  memory 
environment  was  validated.  The  tests  performed  using 
"shtest"  indicated  that  shared  core  allocation  and 
deallocation  of  a process's  data  was  properly  managed. 
Additionally#  since  SSUNIX  benchmark  timing  data  was  so 
nearly  identical  to  that  of  the  other  systems#  the  data 
segment  alignment  capability  had  no  sionificant  effect  on 
system  performance. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


The  primary  goal  of  this  thesis*  an  extension  of  the 
UNIX  memory  manager  to  orovide  data  segment  al ignment  with 
system  protection*  was  successfully  implemented  in  the  form 
of  S3UNIX.  Performance  results  were  encouraging.  However* 
before  the  benefits  of  this  svstem  can  be  fully  realized* 
other  related  develooment  work  in  the  Signal  Processing  and 
Display  Laboratory  is  necessary.  This  chapter  provides 
recommendat ions  directed  toward  the  development  of  a total 
svstem  supoort  oackage  for  the  laboratory's  display 
processor.  Also  included  is  a recommendation  for  further 
research  in  the  area  of  segmented  memory  management. 


A.  CONTROLLED  MEMORY  ALLOCATION 


Several  different  operating  systems  f or  the  display 


processor  have  been  oeveloped  to  orovioe  suoport  for  special 
peripheral  devices.  Two  0f  these  systems  were  designed  to 


provide  process  alicnment  in  a particular  area  of  memory! 
one  tor  CSP  125  processes*  and  another  for  vfi  processes. 
The  existence  of  a number  of  different  ocerating  systems* 
each  with  a particular  aoplication*  causes  a sianificant 
conf igurat i on  control  problem  in  the  laboratory.  Since 


SSUNIX  was  designed  with  these  soecific  aoplicattons  in 
mind*  a direct  i mpl ement at i on  of  this  system  on  toe  display 


processor  would  simolify  the  system  conf  igurat  ion  control 
problem. 
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B.  MULTIPROCESSOR  INTERFACE 
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As  indicated  in  Figure  1#  the  PDP-ll/3a  slave  processor 
is  presently  treated  as  an  independent  system  peripheral. 
The  design  work  done  by  Grav  1 51  has  not  yet  been  tested  in 
the  mul t iprocessor  environment  for  which  it  was  intended. 
Additionally#  the  hardware  interfaces  for  the  32K  word 
shared  core  area  and  the  VG  display  device  have  not  been 
implemented.  The  dashed  lines  in  Figure  l depict  the 
configuration  required  to  complete  the  mul t iprocessor 
interface.  Once  this  is  done#  implementation  of  the  slave 
processor ' s operat i ng  system  and  integration  of  SSUNIX  into 
the  mul t iprocessor  environment  could  follow.  Investigation 
of  the  communication  reouirements  and  protocol  between  the 
master  processor  and  the  slave  processor  is  required.  Also# 
the  i nter-orocessor  graohics  support  package  desiqned  by 
Visco  1121  must  Pe  reviewed  to  ensure  prooer  interface  with 
the  "getshr"  and  "freeshr"  system  calls  of  SSUNIX.  Only 
si i qht  modi fication  to  SSUNIX  would  be  reoui red  to  establish 
this  interface.  One  sugqesteo  aporoach  is  to  implement 
Visco's  "rtime"  and  "nonrtime"  system  calls  in  SSUNIX  to 
perform  the  functions  as  "getshr"  and  "freeshr".  This 
approach  has  the  advantage  of  reouirino  only  simole 
modifications  to  SSUNIX  and  no  modi fications  to  the  graphics 
interface  routines.  Another  possibility  is  modifying  the 


as 


Vector  General  routine*  to  acauire  shared  core  via  "getshr". 
and  release  it  via  "freeshr". 

C.  INVESTIGATION  OF  SWAPPING  POLICIES 

The  disadvantage  of  segmented  memory  management 
requiring  a greater  number  of  cooy  operations  for  process 
swapping  has  been  stated  previously.  An  interesting  topic 
for  further  investigation  is  the  develooment  of  an  extension 
to  SSUNIX  (or  SUNIX)  which  implements  swapping  on  a segment 
basis.  Modifications  to  SSUNIX  to  support  this 

i nvest igat i on  would  involve  revision  of  the  orocess 
scheduling  routine  "sched".  the  process  memory  allocation 
routine  "pralloc".  the  routine  for  swapping  processes  out  of 
core.  "xswap".  and  the  routine  for  swepoing  processes  into 
core,  "orswap".  It  is  contended  that,  although  the  memory 
management  function  will  be  slightly  more  complex,  the 
actual  changes  reauired  to  existing  routines  will  not 
degrade  system  oerformance.  In  fact,  since  swapping  is  a 
significant  factor  in  system  overhead,  an  optimum  swapping 
policy  should  enhance  overal l performance. 
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This  appendix  is  intended  to  be  used  with  a copy  of  the 
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source  code  for  UNIX  (Version  6),  SUNIX  and  SSUNIX.  It 
contains  documentation  of  the  modifications  made  to  UNIX 
control  blocks  to  implement  the  two  new  segmented  systems. 
Source  code  for  these  control  blocks  in  the  UNIX  form  is 
found  in  the  directory  /usr/sys.  Source  code  for  the 
modified  versions  can  be  found  in  the  directory 
/usr/sys. suni x on  the  disolay  processor's  file  system.  The 
format  of  this  apoendix  and  some  of  the  documentation 
contained  herein  are  i dent i ca 1 to  APPENDIX  A of  Ref.  R. 
Each  control  block  is  described  under  an  upper  case  roman 
letter.  The  control  block  name  is  followed  by  the  source 
code  file  in  which  it  is  found.  An  overview  and  a 
description  of  siqnificant  data  elements  is  provided  for 
each  control  block. 


B.  SHRMAP,  share. h 
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1.  Overview 

SHRMAP  is  a structure  containina  NSHARE  free  memory 
maps  of  shared  core  regions.  NSHARE  is  a tunable  parameter, 
also  found  in  "share. h"#  which  specifies  the  number  of 
shared  core  areas  in  the  system.  This  control  block  is  not 


This  control  block  is  not 


I 
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found  in  UNIX  or  SUNIX.  Each  map  in  SHRMAP  is  an  integer 
array  containing  the  physical  block  number  and  size  of  an 
unallocated  memory  area.  The  maps  are  sorted  in  physical 
block  number  order.  This  configuration  is  identical  to 
COREMAP  and  SWAPMAP.  Documentation  of  "malloc.c"  in 
APPENDIX  B describes  the  memory  management  primitives  which 
manipulate  the  free  memory  maos. 

2.  Significant  Data  Elements 

a.  int  shmap (SHMAPSIZ1 

This  is  the  specification  for  a single  shared 
memory  map  contained  in  SHRMAP.  SHMAPSIZ  is  a tunable 
parameter  defined  in  "share. h". 


b.  char  *m«-size 

This  is  the  size  of  the  free  area  in  64-bvte 

blocks. 

c.  char  *m«*addr 

This  is  the  physical  block  number  of  the 

beginning  of  the  free  area  in  the  shared  core  region.  If 

this  value  is  zero,  it  marks  the  end  of  the  map. 


C.  SHARE,  share. h 


1.  Overview 

A SHARE  contains  certain  control  information  aoout  a 
shared  core  region.  There  is  one  of  these  control  clocks 
for  each  of  the  NSHARE  reaions.  Share  is  not  defined  in 
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UNIX  or  SUNTX 


2.  Significant  Data  Elements 

a.  int  basaddr 

This  is  the  physical  block  number  of  the  base  of 
the  shared  core  region  in  memory. 

b.  int  hiaddr 

This  is  the  physical  block  number  of  the  too  of 
the  shared  core  region. 

C . char  nusef  1 a 

This  is  a f 1 ao  which  indicates  that  the  shared 
core  region  is  in  use  by  a resident  memory-shar i ng  process. 
Further  details  on  its  use  are  Provided  in  apoendix  B under 
the  documentation  of  " shal 1 oc .c * . 

d.  char  ckflg 

This  is  a flag  which  indicates  that  no  orocesses 
are  to  be  allocated  memory  soace  within  the  bounds  of  the 
shared  region.  Its  use  in  "mellocO"  is  documented  in 
APPENOIX  B. 

0.  PPUCf  proc.h 

1.  Overview 

One  PPOC  is  allocated  for  each  active  process  in  the 
system.  The  PROC  exists  for  the  life  of  the  orocess.  PKOCS 
are  maintained  in  an  array  called  "jroc"  which  is  WPROC  in 
size.  This  array  is  cermanently  resident  in  main  memory  and 


contain*  *11  oer  process  information  which  cannot  be  swapped 
out  of  main  memory. 

2.  Significant  Oata  Elements 

a.  char  o«*flag 

This  is  a word  of  flaps.  Bit  0 of  this  word  is 
the  SLOAD  flag.  If  it  is  set#  the  process  is  resident  in 
main  memory.  Bit  1 is  the  SLOCK  flag.  If  it  is  set#  the 
process  is  locked  in  memory  and  may  not  be  Swaoped  out.  In 
SSUNIX,  this  bit  is  set  to  lock  memorv-shar i nq  orocesses  in 
memory.  Bit  2 of  this  word  is  the  SSWAP  flag.  If  it  is 
set#  the  process  is  being  swaoped  out. 

b.  int  p«-ador 

This  variable  is  oresent  only  in  UNIX.  If  the 
process  is  resident  in  main  memory#  it  is  the  physical  block 
number  of  the  process's  UVECTOR.  If  the  process  is  swapped 
out#  it  is  the  swap  device  block  number  of  the  swapped 
i maqe . 

c.  int  o«-size 

This  variable  is  oresent  only  in  UNIX.  It  is 
the  size  of  the  process's  swappable  imaqe  in  6<4-byte  blocks. 

d.  int  p«-textp 

This  is  a pointer  to  the  process's  TEXT.  If  the 
value  is  zero#  the  process  does  not  have  shared  text. 
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e.  int  pecaddr 

This  variable  is  present  only  in  SUNIX  and 
SSUNIX.  It  is  the  main  memory  physical  block  number  of  the 
process's  UVECTOR  while  the  process  is  in  memory. 

f.  int  pedaddr 

This  variable  is  present  only  in  SUNIX  and 
SSUNIX.  It  is  the  swap  device  block  number  of  the  process's 
swap  space.  If  it  is  zero,  the  process  has  no  swap  space. 


g.  int  pedsize 

I I 

This  variable  is  present  only  in  SUNIX  and 
SSUNIX.  It  is  the  size  of  the  process's  data  segment  in 

I I >* 


64- byte  blocks. 


h.  int  p*-ssize 

This  variable  is  present  only  in  SUNIX  and 
SSUNIX.  It  is  the  size  of  the  process’s  stack  in  64-byte 
blocks. 

E.  * UVECTOR#  user.h 

1.  Overview 

The  structure  "user"  is  referred  to  as  the  UVECTOR. 
One  of  these  structures  is  part  of  each  swappable  process 
image.  The  UVECTOR  contains  all  process  data  that  is  not 
needed  when  the  process  is  not  in  control  of  the  processor, 
when  the  process  is  in  control  of  the  processor#  its  UVECTOR 
resides  at  a fixed  location  in  the  operating  system  data 
soace . 
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2.  Significant  Oata  Elements 
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a.  int  u<*uisa  (lb! 

In  UNIX  this  array  contains  the  60-byte  block 
di so  1 acement s from  the  start  of  the  region  of  the  process's 
data  and  stack  pages.  In  SUNTX  and  SSUNIX  this  array  is  not 
used. 

b.  int  ueuisdtlbl 

This  arav  contains  the  prototypes  of  the 
process's  user  I-space  and  D-space  page  descriptor 
regi sters . 

c.  int  u«-tsi2e 

This  is  the  size  of  the  process’s  shared  text 
segment  in  64-byte  blocks. 


d.  int  u«-dsize 

This  is  the  size  of  the  process’s  data  segment 
in  64-byte  blocks. 

e.  int  u«-ssize 

This  is  the  size  of  the  process’s  stack  segment 


in  64-byte  blocks. 
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ma  i n ( ) 


a.  Parameters 

This  function  has  no  oarameters. 

b.  Functional  Oescriotion 

This  is  the  operating  system  initiation 
function.  Physical  memory  configuration  is  det «mi ned#  User 
memory  space  is  cleared#  and  all  system  free  maos  are 
initialized.  Process  0 and  Process  t are  created.  In 
SSUNIX,  the  soec i f i cat i on  array  for  shared  core 
con f i gu rat on # "shmem"#  is  found  in  the  file  "main.c".  This 
function  utilizes  "shmem"  to  initialize  the  SHRMAPs  and 
SHARES  described  in  APPENDIX  A.  Shared  core  configuration 
changes  are  managed  by  modifyinq  the  entries  in  "shmem". 
Upon  completion  of  initiation  tasks#  the  process  scheduling 
routine#  "sched"#  is  called.  "Sched"  then  runs  until  the 
ooerating  system  crashes  or  is  otherwise  terminated. 

c.  Returned  Values 

This  function  does  not  return. 

d.  Error  Conditions 

An  error  occurs  if  the  system  clock  cannot  be 


est  ab 1 i shed 


2,  estabur (nt >nd>ns»ieo) 


a.  Parameters 

The  first  three  oarameters  are  the  sizes  of  the 
current  process's  shared  text#  data  and  stack  seqments  in 
64-byte  blocks.  The  last  oarameter  is  a separation  flap 


that  is 

set 

if  the  process  has 

split  i nst  ruct i on 

ana  date 

spaces. 

The 

current  process's 

UVECTOR  is  an 

imol ied 

parameter 

• 

b.  Functional  Descriotion 

This  function  first  checks  the  validity  of  its 
arguments.  It  loads  the  orototypes  of  t he  memory  management 
page  descriptor  registers  into  the  array  u«-uisdfJ  found  in 
the  current  UVECTOR.  In  UNIX  it  also  loads  page  start 
displacements  measured  in  blocks  from  the  beginning  of  the 
region  or  text  into  the  array  u«-uisall  found  in  the  current 
UVECTOR.  The  array  u^uisatl  is  not  loaded  in  SUNIX  and 
SSUNIX . Its  values  are  are  not  required  since  the  values  of 
the  oarameters  are  olaced  in  the  variables  u«-tsize»  u^dsize# 
u«-ssize#  and  u^seo  in  the  current  UVECTOR.  In  all  versions# 
"sureg"  is  called  to  load  the  actual  memory  management 
regi sters. 

c.  Returned  Values 

If  the  parameters  are  invalid#  minus  one  is 
returned#  otherwise#  a zero  is  returned. 


d.  Error  Condition* 


The  minus  one  return  indicate*  an  error  to  the 


caller. 


3.  cksi *e(nt * nd.ns, sep) 


a.  Parameters 

The  parameters  are  the  same 
"estabur (nt .nd.ns# sep) " described  above. 


as 


for 


b.  Functional  Oescriotion 

This  function  is  present  only  in  SUNlX  and 
SSUNIX.  It  checks  its  oarameters  to  see  if  they  are  valid. 


c.  Returned  Values 

If  the  oarameters  are  invalid,  a minus  one  is 
returned.  Otherwise,  a zero  is  returned. 


d.  Error  Conditions 

A minus  one  return  indicates  an  error  to  the 


caller. 


C . ma 1 1 oc  .c 


1 . ma  1 1 oc (mp . s i ze ) 


a.  Parameters 

The  parameters  are  a oointer  to  a free  memory 
map  array  and  the  size  in  blocks  of  the  region  to  be 
allocated  from  the  mac. 
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b.  Functional  Description 

This  function  allocates  soace  in  main  memory  and 
on  the  swap  device.  If  User  free  memory  space  is  to  be 
allocated/  the  first  parameter  must  point  to  CQR£MAP/  and 
the  size  must  be  specified  in  6b-byte  blocks.  If  swao  space 
is  to  be  allocated/  the  first  parameter  must  point  to 
SWAPMAP,  and  the  size  is  specified  in  256-word  sectors.  If 
shared  core  is  to  be  allocated/  the  first  parameter  must 
point  to  a SHRMAP/  and  the  size  is  soecifiea  in  feb-Dvte 
blocks.  In  SSUNIX  only/  this  function  checks  the  global 
flag/  "sharflg"/  if  COREMAP  is  specified.  If  "sherflg"  is 
set/  the  function  must  then  check  the  “ckfla"  in  each  SHARE 
before  allocating  space  in  COREMAP.  If  a "ckflg"  is  set/  a 
free  area  which  incluoes  any  part  of  that  particular  shared 
region  will  not  be  allocated. 

c.  Returned  Values 

If  allocation  is  successful/  this  function 
returns  the  physical  block  number  of  the  base  of  the 
allocated  area.  Zero  is  returned  if  space  is  unavailaole. 

d.  Error  Conoitions 

A zero  returned  value  indicates  allocation 
failure  to  the  caller. 

2.  mf ree fmo/ s i ze / aa ) 
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••  Parameters 

The  first  two  Parameters  are  the  same  as  those 


for  "malloc"  described  above.  The  thiro  parameter  is  a 
physical  block  number  of  an  area  of  main  memory  or  swap 


space. 


b.  Functional  Oescriotion 

This  function  frees  tha  soecifiea  area  in  the 
specified  free  mao.  If  the  first  parameter  points  to 
COREMAP t the  area  is  freed  in  the  User  free  memory  mao.  If 
the  first  parameter  points  to  SHAPMAP,  the  space  is  freea  in 
the  free  mao  of  the  swao  device.  In  SSUNIX  onlv»  if  the 
first  parameter  points  to  a SHRMAP,  the  area  is  freed  in  the 
map  of  that  particular  shared  core  region.  Sizes  are  in 
64-byte  blocks  if  COREMAP  or  a SHRMAP  is  specified/  and  in 
256-word  sectors  if  ShAPMAP  is  specified. 


c.  Returned  Values 


The  value  returned  by  this  function  is  not 


checked. 


a.  Error  Concitions 


This  function  has  no  error  conditions. 


3.  ckmap0 1 a,  rha) 


a.  Parameters 


The  parameters  are  the  low  address  and  high 
address  in  ohysical  clock  numbers  of  a reoion  of  main  memory 
soace.  COREMAP  is  an  implied  parameter. 


b.  Functional  Description 

This  function  is  present  in  SSUNIX  only.  It 
checks  COREMAP  to  determine  if  the  soecified  region  of  main 
memory  is  free.  If  the  area  is  free/  it  is  removed  from 
COREMAP  and  the  map  is  rebuilt  to  reflect  the  removal.  In 
order  to  rebuild  the  mao/  several  boundary  alignment 
conditions  are  checked.  The  position  of  the  free  area 
boundaries  in  relation  to  the  boundaries  specified  in  the 
parameters  determines  the  algorithm  used  to  sort  and  rebuild 
the  map.  This  function  is  used  in  conjunction  with  the 
shared  core  allocation  function/  "shalloc"/  described  below. 

c.  Returned  Values 

If  the  specified  area  is  free  and  was  removed 
from  COREMAP/  a one  is  returned.  If  any  part  of  the  area  is 
in  use/  a zero  is  returned. 

d.  Error  Conditions 

This  function  has  no  error  conaitions. 

<1.  sha  1 1 oc  ( scname  ) 
a.  Parameters 

The  oarameter  is  an  inteoer  value  which 
specifies  a particular  shared  core  region.  The  pROCs  and 
TEXTs  of  all  orocesses/  the  current  process's  UVECTOR/  tne 
SHAPEs/  and  the  SHR^APs  are  all  implied  parameters. 
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b.  Functional  Description 

This  function  is  oresent  only  in  SSUNIX.  It 
performs  the  shared  core  allocation  process  by  acauirinq  the 
region#  reservinq  it  for  memory-sharing  processes/  and 
positioning  the  caller's  data  segment  in  it.  The  function 
first  checks  the  validity  of  its  input  argument.  The 
"ckflq"  for  the  specified  region  and  the  global  "sharflg" 
are  set  to  prevent  allocation  of  space  within  the  region 
during  the  acquisition  process.  To  ensure  that  the  callinq 
process  is  not  within  the  bounds  of  the  shared  core  area 
that  it  is  trying  to  acquire/  it  is  swapped  out  of  memory 
using  "ceswap".  Since  "malloc"  will  not  allocate  space 
within  the  region/  when  the  process  returns  to  memory  it 
will  not  interfere  with  its  own  acquisition  process.  The 
"nuseflg"  of  the  shared  core  area  is  checked  to  determine  if 
the  area  has  been  previously  acquired  and  reserved  for 
sharing.  If  the  area  has  been  reserved/  the  caller’s  data 
segment  is  allocated  in  the  SHRMAP  and  then  copied  to  the 
allocated  space.  If  the  area  is  not  reserved/  "ckmao"  is 
called  to  determine  if  it  is  free.  If  it  is  not  free/  the 
PROCs  are  scanned  to  find  processes  with  seoments  in  the 
area.  Interfering  processes  are  swapped  out  of  memory  until 
the  region  is  free.  "Ckmap"  Performs  the  actual  reservation 
process  by  removing  the  region  from  CORFMAP.  The  caller's 
data  segment  is  then  allocated  in  the  SHRMAP  and  cooied  to 
the  allocated  scace.  In  any  case/  after  the  orocess’s  data 
segment  has  been  copied  to  the  region/  the  process  imaoe  is 
locked  in  main  memory  by  setting  the  -SLOCK  flag  in  the  PROC. 
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c.  Returned  Values 

If  the  shared  core  allocation  process  is 
successful?  the  physical  block  number  of  the  base  of  the 
caller’s  data  segment  is  returned.  If  unsuccessful?  a minus 
one  is  returned. 

d.  Error  Conditions 

The  minus  one  return  indicates  an  error  to  the 
caller.  This  value  can  result  from  one  of  two  error 
conditions:  improoer  inout  oarameter?  or  failure  to  allocate 
the  process's  data  seament  to  the  shared  core  region. 

5.  shfree(o) 


a. 

Parameters 

The  oarameter  is  a pointer  to 

the 

calling 

process ' s 

PROC.  The  SHARES  and  SHRMAPs 

are 

i mo  1 i ed 

parameters. 

b.  Functional  Description 

This  function  is  oresent  only  in  SSUNIX.  It  is 
used  to  free  the  caller's  shared  core  asset.  It  first 
checks  to  see  if  the  caller  is  a memory-shar i ng  process.  If 
so?  that  orocess's  data  segment  is  deallocated  in  the  SHRMAP 
of  the  region  that  it  occupies.  If  there  are  no  other 
memory-shar i nq  processes  remaining  in  the  area?  it  is  freed 
in  CQREMAP  and  the  caller's  imaoe  is  unlocked.  If  any 
memory-shar i no  processes  remain?  the  caller's  imaoe  is 
unlocked  and  swapoed  cut  of  memory.  In  this  case?  the  space 


occupied  by  the  data  segment  is  not  freed  in  CORE^AP  since 


the  area  must  remain  reserved. 

c.  Returned  Values 

The  values  returned  bv  this  function  are  not 

checked. 

d.  Error  Conditions 

This  function  has  no  error  conditions. 

0.  sig.c 

l.  coreO 

a.  Parameters 

The  current  process's  UVECTOR,  PROC,  TEXT  and 
address  space  are  implied  parameters. 


b.  Functional  Description 

This  function  creates  a memory  image  of  the 
current  Process's  UVECTOR.  data,  and  stack.  In  UNTX  this 
function  uses  "estabur"  to  redefine  the  process's  virtual 
address  space  and  make  the  data  and  stack  contiguous.  It 
then  writes  the  data  ar.d  stack  in  one  output  operation.  In 
SUN  IX  and  SSUNIX  this  is  impossible  because  the  data  and 
stack  may  not  be  physically  contiguous.  Two  output 
operations  are  reouired.  one  for  the  data  and  one  for  the 
stack.  If  an  error  occurs  during  an  output  operation,  an 
indication  is  left  in  u^uerror  in  the  UVECTOR  of  the  current 
process. 
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c.  Raturnsd  Values 


This  function  returns  zero  if  successful  end  one 
i f en  output  error  occurs. 

d.  Error  Conditions 

The  one  return  indicates  an  error  to  the  caller. 


■ i 


2.  grow(sp) 


| 

ft 


a.  Parameters 

The  parameter  is  the  value  of  the  current 
process 's  User  stack  pointer.  The  cur ren t process ' s U VECTOR 
and  PROC  are  implied  parameters. 


b.  Functional  Descriotion 

This  function  is  called  asynchronously  when  the 
current  process's  stack  attempts  to  expand  byond  the  space 
allocated  for  it.  This  function  calculates  the  number  of 
blocks  that  the  stack  must  be  increased*  validates  the  new 
stack  size#  and  acquires  the  memorv  that  is  needed.  In 
UNIX*  "expand"  is  called  to  establish  the  new*  larger 
address  space  for  the  entire  process  image.  In  SUNIX  and 
SSUNIX*  this  function  attempts  to  acquire  the  needed  space 
by  in-core  expansion  cf  the  stack  segment’.  If  unsuccessful* 
it  calls  "ceswap"  to  acquire  the  soace  bv  swapping.  If 
successful*  it  copies  the  old  stack  to  the  new  soace  and 
frees  the  old  memory.  In  all  versions  the  newly  acquired 
soace  is  cleared  and  "estabur"  is  called  to  reload  the 
memory  manaaement  registers. 


bl 


a.  Parameters 

The  PROCs  and  TEXTs  of  all  orocesses  are  implied 

parameters  . 

b.  Functional  Description 

This  function  searches  for  swapoed  out  orocesses 
that  "deserve"  to  be  returned  to  memory.  It  selects  the 
most  "deserving"  orocessl  acauires  space  for  it  by  sweeping 
out  other  processes  if  necessary;  and  returns  it  to  main 
memory.  In  SUNTX  and  SSUNIX  two  new  functions  are  used: 
"oralloc"  to  acauire  main  memory  for  the  process*  and 
"orswap"  to  swao  it  in. 

c.  Returned  Values 

This  function  does  not  return.  It  is  the  basic 
instruction  loop  for  Process  0.  It  goes  to  sleep  and  is 
reawakened  about  once  per  second  by  the  clock  function. 
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d.  • Error  Conditions 


In  UNIX#  if  a swao  input  or  output  error  occurs, 
"swap  error"  will  be  sent  to  the  console  and  the 


system  will  crash.  In  SUNIX  and  SSUNIX,  the  swap  operations 
occur  in  "prswao"  so  no  error  messages  are  generated  here. 


2.  neworoc(nrp) 

a.  Parameters 

t 

The  parameter  is  a pointer  to  a PROC  to  be 
established  for  a child  process.  The  current  process's 
UVECTOR,  PROC,  and  TEXT  are  implied  parameters. 


b.  Functional  Description 

This  function  creates  an  exact  duolicate  of  the 
current  process  as  a child  of  the  current  process.  It  first 
makes  the  aopropriate  entries  in  the  child  and  parent  PROCs 
and  in  the  TEXT  if  one  exists.  It  then  attempts  to  acauire 
memory  for  the  child  process.  If  it  is  successful,  it 
simply  cooies  the  parent's  image  to  the  new  memory.  If  it 
fails,  it  swaos  out  a copy  of  the  parent  to  be  returned  to 
memory  as  the  child.  In  SUNIX  and  SSUNIX,  a new  function, 
"oralloc",  is  used  to  attemot  to  acquire  memory  for  the 
chi  Id. 


c.  Returned  Values 

This  function  returns  zero  to  the  parent 
process.  The  return  to  the  child  does  not  come  from  this 
function,  but  from  the  schedulino  function  "swtch".  The 
child  can  identify  itself  as  the  child  because  "swtch" 
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returns  a one  to  It.  This  is  one  of  the  most  important  and 
subtle  phenonena  in  UNIX. 

d.  Error  Conditions 

If  the  PROC  pointed  to  by  the  parameter  is 


already  allocated  to  an  active  process*  the  message  "no 
procs"  will  be  sent  to  the  console  and  the  system  will 
crash . 

3.  expand(news i ze)  * exoand (newd* news ) 


a.  Parameters 

In  UNIX#  this  function  is  called  with  a single 
argument*  the  new  reaion  size.  In  SUNIX  and  SSUMIX#  this 
function  is  called  with  a pair  of  arguments:  the  new  data 
si2e  and  the  new  stack  size.  The  current  process's  PROC  and 
UVECIOR  are  implied  parameters. 


two  new  sizes  in  p«-dsize  and  o«-ssize  in  the  PRO C.  In  UNIX, 
the  function  calls  "xswap"  to  perform  the  swapping 
operation.  In  SUNIX  and  SSUNIX,  the  new  function  "ceswap" 
is  used.  In  UNIX,  "sureg"  is  called  to  load  the  memory 
management  reoisters.  In  SUNIX  and  SSUNIX  this  is  not 
necessary • 


c.  Returned  Values 


The  return  values  of  this  function  are  not 
checked.  The  caller  has  no  way  of  knowing  if  the  process 
was  increased  in  size  by  direct  expansion  or  by  swapping. 
In  UNIX,  if  the  process  is  swapoed  out,  this  function  does 


not  return  to  its  caller.  The  return  comes  from  a 
subseauent  call  to  "swtch"  after  the  process  has  returned  to 


memory  . 


d. 


Error  Conoi t ions 

This  function  has  no  error  conditions. 


u.  ceswao (ods ,oss  ) 


a.  Parame.ters 

The  parameters  are  the  current  process’s  data 
and  stack  segment  sizes  in  64-byte  blocks. 

b.  Functional  Description 

This  function  is  oresent  only  in  SUNIX  and 
SSUNIX.  It  is  called  to  perform  core  exoansion  swaooing. 
It  calls  "xswap"  to  do  the  actual  swapping  ana  then  calls 
"swtch"  to  reschedule  the  process  immediately. 
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c.  Returned  Values 

This  function  does  not  return  to  the  caller. 
The  return  comes  from  a subsequent  call  to  "swtch"  after  the 
process  has  returned  to  memory. 

d.  Error  Conditions 

This  function  has  no  error  conditions. 


F . svs 1 .c 

1.  execO 

a.  Parameters 

The  current  process's  UVECTOR*  PROC*  and  TEXT 
are  imolied  parameters.  Because  this  function  is  a svstem 
call*  the  array  u*-uaro  U in  the  UVECTOR  contains  additional 
arguments.  See  Ref.  11. 


b.  Functional  Oescriotion 

This  system  call  is  used  by  the  current  process 
to  invoke  a new  program.  It  copies  any  proa ram  a rgument s to 
a Duffer*  unlinks  from  the  old  TEXT*  frees  its  old  main 
memory  soace*  establishes  a new  TEXT  if  the  new  program  has 
shared  text*  acauires  memory  space  for  the  new  data  and 
stack  segments*  clears  the  reaion  acquired*  reads  in  the  new 
program's  data*  copies  the  arauments  to  the  new  stack*  and 
changes  the  memory  management  registers  to  reflect  the  new 
address  soace.  In  UNTX*  "expand"  is  called  to  free  the  old 
memory  space*  in  SUNIX  and  SSUNIX*  a new  function*  "prfree"* 
is  used.  In  UNIX,  "estabur"  is  used  to  validate  the  new 
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memory  requirements#  in  SUNIX  end  SSUNIX#  the  new  function 
"cksize"  is  used.  In  SUNIX  and  SSUNIX,  only  the 
uninitialized  portion  of  the  data  segment  is  cleared  before 
the  copy  operation. 

c.  Returned  Values 

This  system  call  returns  to  the  caller  only  if 
it  encounters  an  error.  If  no  error  occurs#  it  returns  to 
the  first  instruction  of  the  new  orogram. 

d.  Error  Conditions 

This  function  returns  an  error  to  the  caller  if 
the  memory  reauirements  of  the  new  program  are  invalid. 

2 . ex i t ( ) 

a.  Parameters 

The  current  process’s  UVECTOR,  PROC#  and  TEXT 
are  implied  parameters. 

b.  Functional  Description 

This  function  is  the  system  call  used  to 
terminate  the  calling  process.  It  clears  all  signals# 
closes  any  open  files#  unlinks  from  the  current  TEXT, 
acaui res  a block  on  the  swap  device#  copies  the  first  256 
bvtes  of  the  UVECTOR  to  the  block#  and  frees  main  memory 
soace  held  by  the  process.  In  SUNIX  and  SSUNIX#  the  old 
memory  area  is  freed  by  the  new  function  "prfree".  .The  new 
function  "swfree"  is  used  to  free  any  swap  space.  In  SSUNIX 
only#  if  a process  has  the  SLOCK  bit  set  in  its  PRUC#  the 


69 


tk.n  ♦* 


function  "shfree"  is  called  to  free  any  shared  core  assets 
that  the  process  has  been  allocated. 


c.  Returned  Values 

This  system  call  does  not  return  to  its  caller. 
The  next  function  invoked  for  this  process  is  "wait"/  which 
completes  the  cleanup. 


d.  Error  Conditions 

This  system  call  has  no  error  conditions. 


3.  sbreakO 


a.  Parameters 

The  current  process’s  UVECTQR  and  PROC  are 
implied  parameters.  Because  this  function  is  a system  call/ 
an  aditional  argument/  the  virtual  address  of  the  new  end  of 
the  data/  is  found  in  the  array  u«-uara[l  in  the  UVECTOR. 


b.  Functional  Description 

This  function  is  the  system  call  used  to  change 
the  size  of  the  calling  process's  data  area.  It  calculates 
the  new  data  size  desired  by  the  orocess  and  checks  tne 
validity  of  the  process's  new  total  memory  reaui rements.  In 
UNIX/  "expand"  is  usea  to  establish  the  new  region.  In  UNIX 
and  SSUNIX/  this  function  attempts  to  do  the  work  itself. 
It  puts  the  new  size  in  prdsize  in  the  current  PROC.  If  trie 
new  size  is  smaller/  it  simply  frees  the  excess  storage.  If 
the  new  size  is  larger/  it  attempts  to  acguire  it.  If  this 
fails/  "ceswap"  is  called  to  acquire  the  soace  by  swapping. 
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In  all  systems*  the  newly  acquired  space  is  cleared. 


t 


c.  Returned  Values 

The  values  returned  by  this  function  are  not 

checked. 

d.  Error  Concitions 

If  the  new  storage  reauirement  is  not  valid*  the 
new  space  will  not  be  acquired  and  the  function  returns. 
This  will  usually  cause  the  process  to  terminate  abnormally 
because  of  a memory  management  error. 


G.  text.c 


1.  xswap (p* f f * os ) * x swap (p* f f * oos *oss ) 


P 

v! 
j i-t 1 
fc-'.il 


m 


c. 
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a.  Parameters 

In  UNIX,  this  function  is  called  with  three 
arguments.  In  SUNIX  and  SSUNIX*  it  is  called  with  four. 
The  first  parameter  is  a pointer  to  the  proc  of  a process  to 
be  swapped  out  of  memory.  The  second  parameter  is  the 
memory  free  flag.  In  UNIX*  the  third  parameter  is  the 
process  image  sire  in  64-bvte  blocks.  In  SUNIX  and  SSUNIX, 
the  third  and  fourth  parameters  are  the  sizes  of  the 
process’s  data  and  stack  segments  in  64-bvte  blocks. 

b.  Functional  Description 

In  UNIX,  this  function  allocates  swap  space  for 
the  process  and  swaps  it  out.  In  SUNIX  and  SSUNIX*  this 
function  allocates  space  only  for  those  orocesses  that  do 
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not  already  have  it.  In  all  systems*  memory  is  treed  it  the 
memory  tree  flag  is  set.  This  flag  will  not  be  set  it  this 
tunction  was  called  by  "neworoc"  to  create  a cooy  ot  the 
parent  process.  In  SSUNTX*  when  this  tunction  is  called  to 
swap  out  a process  with  shared  core*  the  memory  free  flag  is 
not  set  if  other  memory-shar i ng  orocesses  remain  in  the 
shared  region. 

c.  Returned  Values 

The  values  returned  bv  this  function  are  not 

checked. 


o.  Error  Concitions 

If  swap  space  must  be  allocated*  but  none  is 
available*  the  message  "out  of  swap  soace”  will  be  sent  to 
the  console  and  the  svstem  will  crash.  If  an  output  error 
occurs  during  the  swap  operation*  the  messaqe  "swap  error" 
will  be  sent  to  the  console  and  the  system  will  crash. 

2.  xalloc(ip) 


a.  Parameters 

The  parameter  is  a pointer  to  the  inode  of  the 
text  segment  that  is  to  be  allocated  or  located.  The 


current  process's  UVECTOR  and  PRQC  and  all  TEXTS  are  implied 
parameters . 
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process  does  not  reouire  shared  text#  this  function  simply 
returns.  If  the  process  does  require  shared  text#  this 
function  searches  the  array  of  TEXTS  for  a previously 
established  TEXT  for  the  reauested  segment.  Tf  one  is 
found#  its  active-process  use  count  is  incremented.  If  the 
requested  segment  is  in  memory#  the  TEXTs  in-memory  count  is 
incremented.  If  a TEXT  has  not  been  established#  an 
unallocated  TEXT  is  located  and  allocated  to  the  text 
segment.  Swao  space  is  allocated  for  the  text  segment.  The 
current  process's  adoress  soace  is  increased  using  "expand" 
to  acquire  space  for  the  new  text  segment.  The  text  seqment 
is  then  read  into  memory  and  cooiea  to  the  swap  space 
allocated  for  it.  The  new  memory  space  acquired  for  the 
text  seqment  is  freed  using  "exoand"  in  UNIX  and  "prfree"  in 
SUN  I X and  SSUNIX.  The  address  of  the  TEXT  is  placed  in 
p^textp  in  the  current  PROC  and  the  process  is  swapped  out 
of  memory.  When  it  returns  to  memory#  the  newly  established 
text  segment  will  return  with  it. 

c.  Returned  Values 

The  value  returned  by  this  function  is  not 

checked. 

d.  Error  Conditions 

If  a TEXT  must  be  establisheo  and  one  is  not 
availaoie#  the  message  "out  of  text"  will  oe  sent  to  me 
console  and  the  system  will  crash.  If  swap  space  must  be 
allocated  and  none  is  available#  the  messaqe  "out  of  swao 
soace"  will  oe  sent  to  the  console  and  the  system  will 
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H.  oage.c 

1 . pral loc (pr) 

a.  Parameters 

The  parameter  is  a oointer  to  a PRQC.  The  TEXT 
pointed  to  by  the  PPQC  is  an  imolied  oarameter. 

b.  Functional  Oescnotion 

This  function  is  oresent  only  in  SUNIX  and 
SSUNIX.  It  acquires  memory  space  for  the  process’s  UVECTOR/ 
data  segment/  stack  segment/  and/  if  necessary/  shared  text 
segment.  Soace  for  the  text  segment  is  acquired  only  if  the 
text  is  not  resident  in  main  memory.  If  allocation  fails. 


all  memory  space  previously  allocated  is  freed. 


c.  Returned  Values 

If  all  allocations  are  successful/  the  physical 
block  number  of  the  base  of  the  UVECTOR  is  returned.  If  any 
allocation  fails,  a zero  is  returned. 

d.  Error  Conditions 

A return  value  of  zero  indicates  an  error  to  the 

caller. 

2.  prswao(rp) 


a*  Parameters 

The  first  parameter  is  a pointer  to  e PROC.  The 
TEXT  pointed  to  by  the  PROC  is  an  implied  parameter. 

b.  Functional  Description 

This  function  is  oresent  only  in  SUNIX  and 
SSUNIX.  It  swaos  a process's  UVECTOR.  data  segments  stack 
segment#  and#  if  necessary#  text  segment  into  main  memory. 

c.  Returned  Values 

The  value  returned  by  this  function  is  not 

checked. 


d. 

Error 

Cond i t i ons 

I f an 

input  error  occurs 

during 

the 

swao 

ooerat i on# 

the  message  "swao  error"  is 

sent  to 

the  con 

so  1 e 

and  the  sys 

tern  w i 1 

l Crash. 
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II.  APPENDIX  C:  SYSTEM  BENCHMARKS 


A.  8ENCH  1,  MONOPROGRAMMING 


chdi r /usr/sys 
sh  reload 
chdir  ken 
cc  -0  -c  slo.c 
c d . . 
cd  dmr 

ed  ipc.c  </usr/bench/edcmd  >/dev/nu11 
choir  /usr/bench 
cc  -0  rftest.c 
bas  tower<toweri n>/dev/nul 1 
od  /usr/sys/conf /maS.s  >/dev/null 
co  /usr/uni*  /dev/null 
chdir  /bin 
sum  *>/dev/nu1 1 
wa  i t 

Chdir  /usr/sys/ken 
rm  slo.o 

chdir  /usr/bench 
rm  a. out 


B.  BENCH  2,  MULTIPROGRAMMING 

chdir  /usr/sys 
sh  rp1oad& 
chdi r ken 
cc  -0  -c  slo.ci 
c d . • 
cd  dmr 

ed  ipc.c  </usr/bench/edcmd  >/dev/nullA 

chdi r /usr/bench 

cc  -0  rftest.ci 

bas  tower<tower i n>/dev/nul 1 A 

od  /usr/sys/conf /m^S.s  >/dev/null& 

CD  /usr/unix  /dev/nulli 
chdir  /bin 
sum  *>/dev/nu1 1 A 
wa i t 

chdir  /usr/sys/ken 
rm  slo.o 

chdir  /usr/bench 
rm  a. out 
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